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Sensor networks are rather challenging to deploy, program, and debug. Current programming lan- 
guages for these platforms suffer from a significant semantic gap between their specifications and 
underlying implementations. This fact precludes the development of (type-)safe applications, which 
would potentially simplify the task of programming and debugging deployed networks. In this paper 
we define a core calculus for programming sensor networks and propose to use it as an assembly 
language for developing type-safe, high-level programming languages. 

keywords: Sensor Networks, Programming Languages, Process-Calculi. 

1 Introduction and Motivation 

Wireless sensor networks are composed of huge numbers of small physical devices capable of sensing 
the environment and connected using ad-hoc networking protocols over radio links (H. These platforms 
have several unique characteristics when compared with other ad-hoc networks. First, sensor networks 
are often designed for specific applications or application domains making software re-usability and 
portability an issue. Sensor devices have very limited processing power (CPU), available memory, and 
battery lifetime, and are often deployed at remote locations making physical access to the devices (e.g. for 
maintenance) difficult or even impossible. For these reasons, programming such large scale distributed 
systems can be daunting. Programs must be lightweight, produce a small memory footprint, be power 
conservative, be self-reconfigurable (i.e. may be reprogrammed dynamically without physical interven- 
tion on the devices) and, we argue, be ( type- )safe. 

To date several programming languages and run-time systems have been proposed for wireless sensor 
networks (see [10] and references therein) that address some of the above issues, but few tackle the 
safety issue. Regiment [16], a sttongly typed functional macroprogramming language, is the closest to 
achieve this goal by providing a type-safe compiler. However, Regiment is then compiled into a low- 
level token machine language that is not type-safe. This intermediate language is itself compiled into a 
nesC implementation of the run-time based on the distributed token machine model, for which no safety 
properties are available. In fact, in general, an underlying model with well-studied operational semantics 
for sensor networks seems to be lacking. The absence of such a model reveals itself as a considerable 
semantic gap between the semantics of the (sometimes high-level) programming languages and their 
respective implementations. 

In this paper we propose Callas, a calculus for programming sensor networks, based on the formal- 
ism of process calculi [6JQ3), that aims to establish a basic computational model for sensor networks. 
The goal is to diminish the above mentioned semantic gap by proceeding bottom-up, using Callas as a 
basic assembly language upon which high-level programming absttactions may be encoded as semantics 
preserving, derived consttucts. Callas is an evolution from a previous proposal ifTTI by the authors, which 
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Figure 1: The syntax of Callas. 



unlike its original sibling provides: (a) decoupled semantics for in-sensor computation (associated with 
the application layer) and networking (associated with the data-link and network layers); b) support for 
a form of timed events; and c) event-driven semantics. 



2 Overview of Callas 

The syntax of Callas is provided by the grammar in Figure [TJ Let a denote a possibly empty sequence 
(X\ . . . a n of elements of some syntactic category a. We let / range over a countable set of labels rep- 
resenting function names, and let x range over a countable set of variables. These sets are pairwise 
disjoint. 

A network 5 is an abstraction for a network of real-world sensors connected via radio links. We write 
it as a flat, unstructured collection of sensors combined using the parallel composition operator. The 
empty network is represented by symbol 0. A sensor [P,Rt>M, T] t '„ is an abstraction for a sensor device. 
It features a running process (P) and a double-ended queue of processes scheduled for execution (R). Its 
memory stores both the installed code for the application (M) and a table of timers for function calls (T). 
These components represent the application layer of the protocol stack for the sensor. The interface 
with the lower level networking and data-link layers is modeled using incoming (/) and outgoing (O) 
queues of messages. The sensors have a measurable position (p) and their own clocks (r), and are able to 
measure some physical property (e.g. temperature, humidity) by calling appropriate external functions. 
The code in M consists of a set of named functions. The syntax / = (x)P represents a function, where / is 
the name, (x) the parameters, and P the body. The / (O) queue buffers messages received from (sent to) 
the network. Messages are just packaged function calls (Z(v)). Finally, T is a set that keeps information 
on timers for function calls. For each timer, a tuple is maintained with the following information: the 
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call to be triggered, the timer period, the time after which the timer expires and, the time of the next call. 

A process P can be one of the following: (a) a value v that represents the data exchanged between 
sensors. It can be a basic value (b) that can intuitively be seen as the primitive data types supported 
by the sensor's hardware or a module (M). The special value sensor represents the module that holds 
the functions installed at the sensor; (b) a synchronous call v.Z(v) to a function / in a module v; (c) a 
synchronous external call - extern Z(v); (d) a timer - timer Z(v) every v expire v, that calls an installed 
function Z(v) periodically, controlled by a timer; (e) an asynchronous remote call - send Z(v), that adds a 
message (/(v)) to the outgoing queue (O); (f) a receptor - receive , that gets a message from the incoming 
queue (/); (g) a module installation - v.install v', that adds the set of functions in v' to v; and, finally (h) a 
let construct that allows the processing of intermediate values in computations. The latter is also useful 
to derive a basic sequential composition construct (in fact, let x = P in P' = P ; P' with x $ fv(P')). We 
make frequent use of this construct to impose a more imperative style of programming. Each function in 
a module has as the first parameter the variable self that is, as usual, a reference to the current module, 
i.e., the one the function belongs to. Each call to a function v./(v) passes v as the first argument in Z(v). 

In the sequel we present two small examples of programs written in Callas. Both examples have two 
components: the code to be run at a base-station (sink) and the code to be run at each of the other nodes 
(sensor). 

Streaming data. The program that runs on the sink starts by installing, in the local memory (M), 
a module with a receiver function and a gather function. The former just listens for messages from 
the network on the incoming queue. The latter simply logs the arguments using a built-in external call. 
Then, it starts a timer for the receiver function with a period of 5 milliseconds for 10 seconds. Finally, 
the sink broadcasts a setup message with a period of 100 milliseconds and a duration of 10 seconds. The 
call is placed in the outgoing queue of the sink (O). In these examples we write install as a compact 
form for sensor, install . 



// sink 
install { 

receiver = (self) 

receive 
gather = ( self , x , y ) 

external log (x , y ) }; 
timer receiverQ every 5 expire 10000; 
send setup(100 ,10000) 

// sensor 
install { 

receiver = (self) 

receive 
setup = ( se I f , x , y ) 

timer sampleQ every x expire y 
sample = (self) 

let x = external time() in 
let y = external data() in 
send gather (x , y) } ; 

timer receiverQ every 5 expire 10000; 
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Each sensor starts by installing a module with a receiver function, similar to that on the sink, and 
setup and sample functions. Then it starts a timer on receiver and waits for incoming messages. When 
a sensor receives a setup message from the network, it sets up another timer to periodically call sample 
in the same module. When this function is executed the local time and the desired data are read with 
external calls and a gather message is sent to the network carrying those values. 

Note that the routing of messages is transparent at this level. It is controlled at the network and 
data-link layers and we model this by having an extra semantic layer for the network (c.f. Figure |4). In 
this example, the messages from the sink are delivered to every sensor that carries a setup function. The 
information originating in the sensors, in the form of gather messages, on the other hand, is successively 
relayed up to the sink (since sensors have no gather functions implemented). 

The maximum value of a data attribute and the MAC address of the sensor that reads it. This 
example follows much the same principles of the above, except that it is a single shot request. Instead 
of computing the maximum value of the data attribute only at the sink, we optimize the program so that 
each sensor has two attributes max_data and max_mac that keep, respectively, the maximum value for 
the data that passed through the sensor, and the associated MAC address. 



// sink 
install { 

receiver = 
receive 
gather = 
external 
timer receiver 
send setup() 

// sensors 
install { 

receiver = (self) 

receive 
setup = (self) 

let x = external data() in 

let y = external mac() in 

self, install { max_data = (self) x 

max.mac = (self) y }; 
send gather (x , y ) 
gather = (self,x,y) 

let val = s e I f . max_data ( ) in 
if x > val then 

self, install { max_data = (self) x 

max.mac = (self) y }; 
send gather (x , y ) ; }; 
timer receiverQ every 5 expire 10000; 

The program that runs on the sink is very similar to that of the previous example. After installing the 
receiver and the gather functions, it starts the receiver and broadcasts a setup message to the network. 
The sensors get the call from the network using their receivers and execute setup. The data and MAC 



(self) 

(self , x , y ) 

log(x,y) }; 
() every 5 expire 10000; 
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(S-init-Send) 



Figure 2: Structural congruence for sensors. 



address are obtained by calling external functions and sent to the network in gather messages. Each time 
such a message is relayed by a sensor on its way to the sink, the relaying sensor checks whether it is worth 
to send the data forward by comparing it with the local maximum. This strategy manages to substantially 
reduce the required bandwidth at the sensors closest to the sink. The sink implementation of gather stops 
the relaying and logs the data. Note that in this example, to simplify, more than one maximum value may 
be recorded at the sink. Also, we use an if —then construct that is not provided in the base calculus but 
that can easily be added for convenience. 

Unlike the previous example, here every sensor will relay gather messages only after some internal 
processing, by its own version of the homonym function. 

Semantics. The calculus has two variable binders: the let and the function constructs, inducing the 
usual definition for free and bound variables. The displayed occurrence of variable x is a binding with 
scope P both in let x = P' in P and in / = (... ,x, ■■ ■ )P. An occurrence of a variable is free if it is not in 
the scope of a binding. Otherwise, the occurrence of the variable is bound. The set of free variables of a 
sensor S is referred to as fv(5). 

We present the reduction relation with the help of a structural congruence, as it is usual [14J, given 
in Figure [2] Here, S-init-Send is the only non-standard rule and provides a sensor with a conceptual 
membrane that engulfs neighboring sensors as they become engaged in communication. This prevents 
the reception of duplicate copies of the same message from the source sensor during a transmission. 

The reduction relation is inductively defined by the rules in Figures [3] and @] Since processes evaluate 
to values, we allow for reduction within the let construct and therefore present the reduction relation 
using the following reduction contexts: ^[[-]] ::= [ j | let x = iff-]] in P. The reduction in a sensor is 
driven by running process P. 

Within sensors reduction proceeds without obstacle while the internal clock t is not such that a timed 
call must be triggered. This is controlled by the predicate noEvent that checks the time of the next 
activation for every timed call against the current time. There is no special reason why the increments 
in the clock are unitary. One could easily assume that each instruction consumes a different number 
of processor cycles and reflect that scenario in the rules. Some rules {e.g. R-let) simply re-structure a 
process and thus we assume that no cycles are consumed. 

Rule R-extern calls a synchronous external function and receives a value as the result. The rules 
R-install-sensor and R-install-module handle module updates. The former takes the module with the 
code installed at the sensor and updates it with the code of another module M' . The resulting new 
module is installed in the sensor. The latter applies only to volatile anonymous modules and therefore 
the resulting module is not installed in the sensor. The rule R-send (R-receive) handles the interaction 
with the network by putting (getting) messages in (from) the outgoing (incoming) queue. Notice that 
receiving a message is non-blocking (R-no-message). The rules R-call-sensor, R-call-module and R- 
no-function handle calls to functions in modules. R-call-sensor selects the function in the sensor's 
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(R-next,R-move) 
(R-let) 
(R-call-sensor) 
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(R-no-function) 
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[P,R>M,TU(l(v),v,v',t)f£ -> [P,P>M,P]^ 
See Definition Q] for the formal meaning of operator 
Figure 3: Reduction semantics for sensors. 
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Figure 4: Reduction semantics for sensor networks. 



module, gets its code and replaces the parameters with the arguments passing the sensor's module M 
as the first argument in variable self. R-call-module is similar to R-call-sensor but uses module M' 
instead of the sensor's module M. Rule R-no-function handles the case of a call to a function that is not 
yet installed. The call is deferred to the end of the run-queue. The idea is that the module containing 
the function may not have arrived at the sensor to be installed and so we postpone the execution of the 
function. 

When a value of t is reached such that it implies the triggering of a call, the rules R-trigger and 
R-expire come into action. Rule R-trigger places a timed function call l(y) at the front of the run- 
queue. The execution of the call is delegated to rule R-call-sensor. Note that only calls to functions 
installed in the sensor (in M) are allowed. Other calls are deferred to the end of the run-queue by the rule 
R-no-function. If the timer has expired, rule R-expire removes the corresponding tuple from T . 

Network level reduction proceeds concurrently with in-sensor processing. It handles the distribution 
of messages placed by the sensors in their outgoing queues. A message broadcast starts with the creation 
of an empty membrane for the broadcasting sensor (rule S-init-Send from the structural congruence). 
Then, each time a new sensor is added to the membrane of a broadcasting sensor (rule R-broadcast), a 
function networkRoute decides where the message in the O queue of the broadcasting sensor should be 
copied into the new sensor. The function can be thought off as implementing the routing protocol for the 
sensor network. The message broadcast ends with the destruction of the membrane, the captive sensors 
becoming again free to engage in communication (rule R-release). 



In this section we present a simple type system for Callas, discuss run-time errors, and prove a type 
safety result guaranteeing that a well-typed sensor network does not get "stuck" while computing. 

Type checking. The syntax for types is depicted in Figure [5] Types z are built from the built-in type j8, 
the types for functions f — > z, where f is the type for parameters of the function and z is its return type, 
the types for the sensor code module (/,• : ?,• — > t,) iG / that is a record type gathering type information for 
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(/,•: $ ->• Ti)i e / 
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Types 

built-in type 
recursive function type 
sensor code type 
anonymous code type 
recursive type 
type variable 



Figure 5: The syntax of types. 



each function of the code module, the types for anonymous code modules {/,• : — > Zi}i & i, recursive 
types, and type variables. The need for distinct code module types comes from the fact that we need to 
distinguish from installing code in the sensor module or in an anonymous module. The ii operator is a 
binder, giving rise, in the standard way, to notions of bound and free variables and alpha-equivalence. 
We do not distinguish between alpha-convertible types. Furthermore, we take an equi-recursive view of 
types fT9l , not distinguishing between a type iia.T and its unfolding r\p.a.r/X]. 

Definition 1. The + operator is defined ( overloaded) for modules, code types, and type environment as 
follows: 



The typing rules for values, processes, sensors and queues are presented in Figures [6] to [9j Type 
judgments for values are of the form T5; Tm; T h v : T, where T5 and Zm are code module types representing 
the types for the built-in functions of the sensor (Zs) and for functions installed in the sensor memory Zm, 
and r is a typing environment mapping variables to types. The rules are straightforward, but notice that 
rule T-sensor assigns the sensor code type Zm to sensor value. 

The judgments for processes are the same as for values. Rule T-extern ensures that no user-defined 
function is executed as a system call and that a system call always belongs to a predefined type z s 
(T5 h / : f — > z). Broadcasting a call (Rule T-send) is only possible if the call can be made locally 

Zm\ r h sensor ./(v) : {}) and for functions that return the empty module, since it is an asynchronous 
remote call and no value is going to be returned (cf. the return value of a system or a local call, which 
is synchronous). Notice that the type system does not distinguish between local and remote functions, 
however such refinement may be interesting and can easily be added. Installing code in the sensor's 
code module (Rule T-sInstall) implies that the module is entirely replaced and that its type is preserved. 
On the other hand, installation over an anonymous module (Rule T-mInstall) is more flexible and only 
requires that functions common to both code modules should agree on their type (vide the definition of + 
operation). When calling a local function the type of the first parameter (Zi) corresponds to the type 
of module containing the function being called (vide operation semantic Rules R-call-sensor and R- 
call-module in Figure [3]). The rules for let and receive are straightforward. Finally, firing an event 
(Rule T-timer) amounts to calling a user-defined function locally. 



. {/, = (m}iel + {lj = {xj)P'j}jeJ = {h = (xi)PiJ'j = {Zj)P'j}ie(l\J),jeJ 

• {It: Zi} ieI + {l'j: z'j} jeJ = {If. z'j} iemje j 

• r 1 +r 2 = (r 1 \r 2 )ur 2 . 
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Ts; Tm;T h ft: j8 T5;Tm;T,x: t hi: t t^; Tjif;rh sensor : (T-built-in, T-var, T-sensor) 

; e/ v/.Ts;TM;ri- v,-: t,- 



[/,■ : T,- -»• Zi] i& h : Xj — >• Xj T 5 ; T M ; T h v : f 

Vi € 7.T 5 ; T M ;r,^- : t m / ,x t : f t - h P, : x t x M < = na.{k : ax t -> T,-},- e/ 

T 5 ; T M ;T h {// = (5';,X I )P,-} ie / : X M ' 
where [/,■ : x, — > T,], e / means either a sensor or an anonymous code type. 
Figure 6: Typing rules for values. 



(t-label, t-seq) 
(T-code) 



x$\~ I '. x — > x Xs;Xm;~T\- v: x Xs\Xm'X \~ sensor .l(v) : {} 
Xs;Xm'X\- extern l(y): x Xs\Xm'X \~ send l(v): {} 



(T-extern,T-send) 



x s ; x M ; r h vi : iia.{U : a?,- -> x t ) m x s ; x M ; T h vi : Ti Ti = {/,■ : T; T,-} ; - e/ 

t 5 ; t m ; r h v 2 : iia.{k : af,- -)■ Tf} ie / x s ; x M ;T \~v 2 : x 2 x 2 = {lj : Xj -> 



T 5 ;TM;rhvi. install v 2 : {} T 5 ;TM;ri- vi. install v 2 : T1 + T2 

(T-SlNSTALL, T-MlNSTALL) 

T5;T M ;ri- v t : Ti Xj\- I: XjX ^ x 2 x s ;x M ;T H V2 : t Ts;T M ;r h P t : n T 5 ;T M ;r,x: r t hf 2 : T2 
x s ;x M ;T\- v 1 .l(v 2 ): x 2 Ts;T M ;r h let x = P 1 in P 2 : x 2 

(T-call,T-let) 

p 1 . n T 5 ;T M ;rh sensor ./(v): {} r s ; x M \T h ViV 2 : jSjS 

T5;Tm;TI- receive : {} — — : ' : - (T-receive,T-timer) 

Xs\Xm'X r timer Z(v) every vi expire V2: {) 

Figure 7: Typing rules for processes. 

Typing judgments for sensor networks are of the form t^; Xm h S. We only comment the rule for typ- 
ing a sensor (Rule T-sensor), in particular, that the type of each function in the sensor's code module (M) 
must agree with predefined sensor's type interface (Tm), apart from the self parameter. 

Typing the run-queue (Rule T-run-queue, Figure©, the incoming and outgoing queues, and the event 
table is equivalent to typing each element of the structure individually (Rules T-comm-queue and T-event- 
queue). Notice that each element of the incoming (outgoing) queue is typable if it can be called as a local 
sensor function. The same holds for timed calls (Z(v)). 

The proofs for our main results (Theorem[6l Theorem|7J and Corollary [8]) are based on the following 
auxiliary results. We call context process, denoted ^ [[P]], the processes resulting from filling its context 
hole. Informally, Lemma Q] states that if a context process is well typed, then the same also holds for 
the process that fills its hole, although not necessarily with an identical type. Lemma |2] states that the 
typability of a context process holds and its type is preserved if we fill the context's hole with processes 
of the same type. Lemma [3] handles module's substitution. Lemmas 0] and [5] are discussed below. 

Lemma 1. Ifx s ; %;fh V\P\ : x, then x s ; x M ;F' Y-P:x'. 



Proof. The proof proceeds by induction on the contexts' structure and both cases are straightforward. 
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t s ;t m ;0HP:_ t s ;t m HP t 5 ;t m ;0 KM: ixa.{h: a% -> T,-} ie / 
V/ € 7.t m H /; : T M T T,- t 5 ; t m ; <D\-tp: j3j3 
T 5 ;TMl~r t s ;tmI-/ Ts;t m I-0 

Tj! Tjlf rU j-7; (T-OFF, T-SENSOR) 

T S ;r M h[P,R>M,T} I t :° 



Ts; t m h [P,/?>M, r]J? T 5 ; T M hS t s ; t m h 5i T S ; Tm r- S 2 



(T-bSensor, T-par) 



t 5 ;tm r- [P,R>M,T} I p c ^ {S} T S ;T M hSi\S 2 
Figure 8: Typing rules for sensor networks. 

T,;T M ;0hP:_ T,.;T M hP T s ; T M ; h sensor ./(v) : _ T 5 ; T M h / 

t s ;t m HP::P t s ;t m h (Z(v)} 

(T-run-queue, T-comm-queue) 

t s ; t m ; 01- sensor ./(v) : _ t s ;t m ;0 h viv 2 v 3 : j8ij8 2 j8 3 Ts;t m ^P 

— — — —7— (T-event-queue) 

t 5 ;t m I- rtbl (/(v),vi,V2,v 3 ) 

Figure 9: Typing rules for queues of messages, processes, and events. 

□ 

Lemma 2. 7/T 5 ;T M ;r h <T[[P]] : z, t s ;t m ;T' h P: and T S ; i M \ P h P' : T',teT S ;T M ;rh?[P']: t. 

Proof. We proceed by induction on the contexts' structure analysing each definition case. Both cases 
follow easily. □ 

Lemma 3. If T 5 ; z M \ T h Mi : Ti awd t s ; t m ; r' h M 2 : T 2 , fftm T S ; z M \ T + T' h M\ + M 2 : n + T 2 . 

Proof. Directly from the definition of + and using Rule T-code. □ 

The Substitution Lemma is used in the proof of the Subject Reduction Theorem, to show the cases 
that involve the replacement of formal by actual parameters, specifically for function call and for the let 
construct. The proof is standard, so we omit it, but the interested reader may find similar proofs in the 
literature, for instance in l2~fl Section 6.3]. 

Lemma 4 (Substitution Lemma). IfXs'^M'XV- v: %' and Ts;Tm',T ,x: r'hP: T, then T5; Tm> T h P[v/x] : T. 

The following results state type invariance during reduction. 
Lemma 5 (Congruence Lemma). Ifts; Tm I - S and S = S', then T5; Tw H S'. 

Proof. We proceed by induction on the derivation tree for 5 = 5'. The proof is straightforward. □ 
Theorem 6 (Subject Reduction). /fTs; Tm I - S and S — > S', then T5; Tm h S'. 

Proof. By induction on the derivation tree for S — > S'. In each case, we proceed by case analysis on the 
last typing rule of the inference tree for T$; Tm h S. □ 
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[^lv.l(v)]},R>M, r]J° ^ if v is not sensor, nor M' (E-call) 

[^[[M'.l{vi . ..v n )]],R>M, T]' p ° ^> if I £ dom(M') or 

(M'(l) = (xi...Jt w )Pand 

n^m) (E-cFunction) 

\ install v],/f >M, T]^ if v is not sensor, nor M' (E-install) 



s = s' 



(E-PAR, E-STR) 



Figure 10: Run-time errors for sensors. 

Type safety. Our claim is that well-typed sensor networks are free from run-time errors. The unary 
relation S i — >, defined as the least relation on networks closed under the rules in Figure [TOl identifies 

err err 

processes that would get "stuck" during computation (reduction). We write 5 for ->[S i — >). 

Our Sensor Networks may exhibit two kinds of failures upon computing: when calling a function or 
when installing a module. In the former, the call may result in a run-time error when the target of the 
call is neither sensor, nor an anonymous module (Rule E-call); or when the function name is unknown 
or there is a mismatch between the number of arguments (vi . . . v„) and the number parameters (jq . . .x m ) 
(Rule E-cFunction). In the latter, an error may occur if we are installing some value that is not a module 
(Rule E-install). 

As an example, recall the gather function from the streaming data example that we sketched below. 
{ gather = (self ,x,y) ...} 
The process 

let t = extern getTime() in send gather(t) 

exhibits a run-time error, since function gather is being called with two arguments instead of three. In 
fact, the above network may reduce using Rules R-extern and R-let, but then we cannot apply Rule 
R-function, since the substitution is not defined. Run-time error Rule E-cFunction captures this kind of 
failure. 

The Type Safety result states that well-typed networks do not incur in run-time errors. 

err 



Theorem 7 (Type Safety). Ifz s ; z M h S, then S 

Proof. We prove the contra-positive result, namely S i — > implies that T5; Tm 1/5, proceeding by induction 
on the definition of S 1 — > relation. □ 

Finally, a well-typed network is free of flaws, at any time during reduction. 
Corollary 8 (Absence of Runtime Errors). If x s ; x M h S and S — ^* S', then S' i42>. 

Proof. By hypothesis T5; Tm l~ S, then, since types are preserved during reduction (Theorem[6]), by induc- 
tion on the length of — >* we obtain t 5 ; t m h 5". Using the Type Safety theorem (Theorem [7]) we conclude 
that 5'^. ^ q 
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4 Related work 

The majority of available programming tools for sensor networks are based on rather low-level pro- 
gramming languages, most notably the module-based idiom nesC [5], which promotes a system level 
programming style on top of a small-scale operating system such as Tiny OS l22l . Other examples in- 
clude C and Prothothreads for Contiki [2] and at the extreme Pushpin |9). 

Moving away from the hardware and system level programming we have virtual machines like 
Mate [8] and its associated core language TinyScript that provide programmers with a suitable abstrac- 
tion layer for the hardware. Middleware platforms such as Deluge [7 ] and Agilla [3] enable higher level 
control of sensor networks for critical operations such as massive code deployment. 

True high-level programming languages such as Regiment lfP71 . Cougar |@), and TinyDB |[T2l ab- 
stract away from the physical network by viewing sensor networks as time varying data streams or as 
data repositories. Regiment, for instance, adopts a data-centric view of sensor networks and provides 
the programmer with abstractions to manipulate data streams and to manage network regions. Although 
Regiment is a strongly typed language — an essential characteristic to enable the scalable development 
of applications — its construction is not based on a formal calculus and it is not clear that the semantics 
is amenable to proving correctness results for the system and applications. 

In fact, the state-of-the-art in the design of sensor network programming languages ifTOl follows, 
invariably, a top-down approach, in which system engineers start by identifying useful patterns and 
abstractions based on case studies of applications and then attempt to provide the programmer with lan- 
guage constructs and system features that reflect these patterns. These building blocks must then be 
compiled into nesC/TinyOS code or some other API that interacts with the low-level operating system. 
The problem with such approaches is that the semantic gap between the original language specifica- 
tion and the actual implementation inevitably precludes a thorough analysis of the correctness of the 
envisioned sensor networking application. 

Seeking a fundamentally sound path towards the development of programming languages for sensor 
networks, we propose a somewhat disruptive bottom-up approach. Inspired by process calculi theory (6) 
[131 . our basic idea is to start by constructing a fundamental programming model, which (a) captures 
the specific computing and communication aspects of sensor networks and (b) enables us to reason 
about their fundamental operations. This approach is justified by the fact that most high-level languages, 
even those that fully abstract from the networking aspects and view sensor networks as time varying data 
streams or data repositories, ultimately map their high-level constructs into a lower level communication- 
centric language and run-time system. 

Previous work on process calculi for wireless systems is scarce. Prasad EUl established the first 
process calculus approach to modeling broadcast based systems. Later work by Ostrovsky, Prasad, and 
Taha [18] established the basis for a higher-order calculus for broadcasting systems. More recently, 
Mezzetti and Sangiorgi [13] discuss the use of process calculi to model wireless systems, again focusing 
on the details of the lower layers of the protocol stack {e.g. collision avoidance) and establishing an 
operational semantics for the networks. 

5 Conclusions 

Discussion. Programming languages based on type safe specifications are fundamental for applications 
where development and debugging can be complex. Sensor networks are one such case. Difficulties in 
physically accessing deployed sensors, resource limitations of the devices, and dynamic ad-hoc routing 
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protocols, all conspire to make the programming and debugging of these infrastructures a difficult task. 

In this paper we present a strongly typed calculus for programming sensor networks. Sensor network 
applications are built by plugging together components called modules. Dynamic reprogramming is 
supported by making modules first class entities that can be exchanged between sensors and by allowing 
modules to be installed locally upon reception on a sensor. A type system provides a static verification 
tool, which allows for premature detection of protocol errors in the usage of modules. This feature is of 
utmost importance when programming large-scale applications for sensor networks, since it eliminates 
many errors that would have to be corrected online, at run-time. We prove two fundamental properties 
of the operational semantics and of the type system, namely, subject reduction and type safety. Together, 
these results establish the calculus as a sound framework for developing programming languages for 
sensor networks. 

Future work. As part of our ongoing work, we are pursuing two different lines of research. First, we 
are exploring the theoretical properties of the calculus. By applying techniques from process calculi the- 
ory we hope to be able to prove fundamental properties of sensor networking applications and protocols 
{e.g. protocol correctness). Second, we designed a core programming language based on the calculus 
and implemented the corresponding compiler and virtual machine. We expect to prove the correctness 
of the virtual machine relative to the base calculus. This will provide an unequivocal link between the 
semantics of the calculus (and core language) and the semantics of higher-level programming languages 
that we implement on top of it. 

Acknowledgments. The authors are partially supported by project CALLAS of the Fundacao para a 
Ciencia e Tecnologia (contract PTDC/EIA/7 1462/2006). 
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